Dropping support for OSX. Moving forward these dotfiles will depend on Linux
systems. Furthermore, since I'm support a ~/bin, the machines that consume these
dotfiles depend on i386 architectures. Linux and i386 are two dependencies that
I'm okay with since the leverage this assumption provides, makes their existence
tolerable.
There is some Google leakage herein, which includes aliases, functions, and
mentions of cloudtop. For now, this is okay. I may break the Google specific
code into its own repository, but for now, this is less maintenance.
This also introduces a ~/.profile instead of erroneously defining environment
variables in my zshrc file, which was unadvised.
This is a large commit and also introduces new aliases, variables, functions
that I accumulated over the past week or so while migrating away from OSX and
onto my new setup. Hopefully in the future I'll be more precise with my commits.
My Emacs installation would fail on new machines because:
* use-package
* evil
* paredit
use-package is needed to install everything else.
evil and paredit were required in functions.el and other places before they were
called like (use-package evil ...). This should improve things but not fix the
entire issue.
Removing more files that clutter my `gst`
This time I ran...
```bash
git rm -r --cached .
```
...which is supposed to help ignore files that `git` already tracks. This may be
the missing piece I've been looking for.
After yet another unpleasant experience starting up GPG on a new system, I
decided to encode my learnings and mistakes as aliases, functions, scripts,
hoping to protect my future me from myself. Fingers crossed!
I've been sloppily managing my fonts for awhile. At this point in time,
it seems reasonable to carry around ttf, otf, and other font files.
These are 4.0K in size anyhow, which doesn't seem burdensome to me for
the convenience I get in return.
Lists the packages installed by `nix-env`. Moving forward, it might be
useful to run something like...
`$ nix_installed >nix-env.txt`
...and commit that to this repository a la the brew.txt file that
previously floated around this repo. For now, I'm unwilling to commit to
that solution, because I'm hoping a better alternative exists.
Perhaps this should be an alias. Still unsure why I write aliases
sometimes and functions other times. It might be worth documenting as a
principle that I can lean on.
Supports ZSH themes based on which device I'm working. This might get
annoying after awhile, but I think the idea of having the prompt reflect
when I'm on a different machine than my own might be useful.
Adds "cloudtop" alias in ssh config.
I documented my consumption of wpcarro/dotfiles in the README. The dream
is to just clone this repo and run `make install`. We'll get there.
TODO: drop support for OSX
TODO: clean up the rest of this README
I have the (package-initialize) call already in wpc-package.el.
I'm unsure how this removal is ending up in a git status because I'm
pretty sure I've never commited that to this repo. Need to tighten
things up I guess.
This repo's history seems to reflect my difficult wrestling with
Git, GitHub, gitignore files. I'm still not sure I understand
everything that's going on.
- support <leader>e* KBDs for quickly editing common configuration files
- prefer dark theme to light theme
- prefer nowrap by default instead of toggling wrap
Disables i3-gaps code temporarily until I get a proper installation
working.
Formats existing code to prefer alignment of text across similar,
adjacent definitions.
Defines new KBDs for screenlocking, music player controls, volume
controls.
Defines a rough manifesto of KBDs and the reasoning behind some choices.
This format string is being used in my i3 config and in my alias for
creating a gPaste. I figured it'd be nice to set a variable that defines
the format. Future me: run `man date` to see what format options are
supported.
pbcopy -> c
pbpaste -> p
While it's nice to expect pbcopy on both OSX and Linux, it's better to
just alias c=pbcopy on OSX and assert on `c` and `p`, which are must
shorter to type.
Since I'm constantly editing vim, emacs, i3, zshrc, functions, aliases,
etc., I should support variables, aliases, and KBDs to make editing,
sourcing these files much more efficient.
Beware and avoid leaking sensitive data.
Options:
- ensure wpcarro/dotfiles remains private while support potentially
sensitive documents
- consider encrypting sensitive documents using gnupg or git-crypt
- consider having someone from the Security team audit the repository to
ensure that nothing sensitive is being leaked
My inconsistent git history-keeping is coming to bite me here. At the
moment, I can only speculate about what went wrong here. The gist is
this: I unintentionally committed files that were supposed to be ignored
This commit removes those files which includes:
- auto-save-list
- elpa packages
- quelpa packages
- misc
Super shared KBDs between i3wm and Emacs for:
- focusing windows (i.e. M-{h,j,k,l})
- deleting windows (i.e. M-q)
More support may be needed, but this is good DWIM behavior for now.
- Prefers "$HOME" to "~/urbint" for current project
- Prefers dark colorscheme
- Allows source-jumping to Emacs (nixify this to remove dep on
path/to/source)
This is a massive diff that I had to do in a hurry - when leaving
Urbint. I'm pretty sure that most of these are updating Emacs packages,
but I'm not positive.
- enable rerere
- prefer less, since bat is my default pager, which doesn't look great
when looking at diffs, patches, etc
- fix broken alias
- support another alias
Accidentally commited the version of this configuration that has this
variable set to false.
Since most of the time, this variable should be true, commiting the true
version will clean up my git status output.
My younger self didn't know that creating repos to house your
configuration was a known pattern! Hence the unweildy name, pc_settings.
This change was a long time coming.
The original idea was to have all of my configuration available on a
USB drive that would bootstrap itself when connected to a Mac. While
this is pretty cool from a Hollywood, hacker-porn standpoint, it is less
desirable to me due to its dependencies. Docker may be the better path
forward.
