The `jshell` alias currently imports libs like guava and jOOL into the `jshell`,
which is nice for experimenting.
Experimenting with keeping some helpful `.jars` in `~/programming/jars`. This
may be a bad idea, and there may exist a more idiomatic way to do this instead
of wrapping `jshell` in an alias, but for now, I need to move on.
Also documents some abbreviations for applications. `jv` will be necessary so
that I don't conflict with `j` or `js` for javascript. Eventually I'll need to
be more organized to avoid naming collisions, but this is okay for now.
This allows me to take advantage of the --app=<URL> flag that google-chrome
supports, which is nice for a version of cider that bleeds all the way to the
window's edges. It makes Cider feel more like a native application experience.
This comes with the default configuration on i3. I removed this KBD originally
because I was hoping to use the $mod+{,Shift+}t KBDs frequently. I still do, but
as I get more comfortable with i3, splits, parent containers, etc. I may prefer
to create terminals this way. We'll see...
NOTE: consider migrating from GH private repo to Google's Git on Borg. This is
preferable since GH gets hacked and private repos can be exposed. While a path
to a Google 3 repo like SpeWall may not pose a large security risk, it certainly
isn't optimal. Imagine a path to a repository whose name leaked a secret
project. Two options:
1. embrace encryption options like Mozilla's `sops` and remain on GH private
2. switch wholesale from private GH to GoB
3. classify "sensitve" parts of dotfiles as such and move those to GoB and keep
everything else on private GH
One added perk of switching to GoB is saving the $7 monthly fee to support
private GH repos.
The nohup.out file was creating a bunch of noise and polluting my FS. It may
have been the correct thing to add, but if it was, I'm unsure why. Removing it
for now since it's been bothering me quite a bit.
Wraps the existing `prodaccess` executable and displays a quote from Google
ENG's fortune db.
Fortune is a GNU tool intended to support random quote compilation, display,
etc. It's pretty interesting.
NOTE: the `prodcertstatus` executable that this function is using as a guard
looks like it might be useful moving forward.
We already have `gcan`... looks like `gca` was already defined by some ZSH git
extension. This further weakens my dependency on that extension, which I think
is a good things.
May need to find a better KBD for `snip_it`, since I really enjoy Tmux's M-s to
switch sessions.
Learned about i3's "edge" concept. Re-supported KBDs for settings split
directions. Also adjusted theme colors.
Also adjusts the formatting of the timezone information to show GMT as LON, EST
as NYC, and Pacific as MTV.
I originally dropped support for these because I wanted to imitate OSX's
screenshot KBDs, which were mod+Shift+{3,4}. I'm not sure I want to imitate OSX
now that I don't have any Apple hardware besides my iPhone. I'm getting more
forgetting those KBDs. At the moment, however, I cannot find a better KBD for my
snip_it function. Stay tuned...
I must not have tested this before adding it to the repository; otherwise, I
would have found this. Oh well... it worked like a charm when copying the GPG
information from my desktop to my laptop.
I used `light` on my MBP running NixOS. I got `xbacklight` working on my Dell
Precision running gLinux. It wasn't easy, and I still don't fully understand the
integration story. Thankfully I'm not alone and the documentation from the Arch
Linux came to rescue (per usual).
In my quest to learn more about terminals, I added a function to output ten
emojis. Technically this tests the same thing as test_unicode.
Unfortunately I couldn't get `st` to output any colored emojis. This is a bit of
a buzzkill for my grand plans to create a terminal-based chat client that
supports emojis.
Defines functions for creating, deleting, renaming files.
Defines functions for encrypting/decrypting files.
Defines functions for archiving/unarchiving files.
Adds TODOs for wishlist items.
Adds `help` function to view `lf` documentation.
TODO: write generic explanation of desire to share KBDs between Emacs, Vim,
other programs that I can link to in documentation to avoid repeating myself.
I'm unsure if this is idiomatic POSIX shell scripting or not, but I generally
prefer function calls to variables. Thankfully things like Haskell don't
differentiate between the two. In other cold and hostile environments like shell
scripting, us programmers must take care to prefer functions to variables where
it makes sense.
If you're going to install things and support that with an aliases, might as
well support the removals of packages with an aliases. Better to keep systems
lean -- especially if entropy is the tendancy.
Separated i3/configuration since some of my devices support XFree86 keysyms
while others do not. This introduced some cascading changes.
- Removed ~/.config/i3/config from this repo. Since I will be switching between
devices semi-regularly and that file will be generated each time I switch to a
different device running an X session, I don't want the i3/config to spam my
`gst` and `gd` when I haven't changed configuration in either config.shared or
config.device.
- Update aliases, variables, etc. to point to config.shared instead of the
generated file.
- Ensure that X sessions generate the i3/config file.
- Ensure that i3 reload and restart command generate the i3/config file.
This seems to resemble Atom's One Dark theme that I'm using in Vim, Emacs,
wallpaper already. Would be nice to keep everything consistent. I should update
the i3 Status Bar and Chrome to support One Dark themes as well.
This change affects:
- alias e
- i3 KBDs
- .xsessionrc
It will be interesting to see how this works over SSH. In theory, the
ALTERNATE_EDITOR variable should kick in and `vim` should be used. Time will
tell if this is the preferred setup. Until then...
See the comment for an explanation about this revision.
- we want to support to GUI
- it's difficult to reuse GUI windows elegantly unless the server is started
from the GUI itself
- consider starting the emacs GUI when X initializes
`company-mode' can be pretty noisy in some modes. In fact, I'm writing this in
`fundamental-mode', which is proving to be equally as noisy as the
auto-completion in `markdown-mode'. Stay tuned for an update that disables
`company-mode' in fundamental mode.
This is intended to be an i3 status bar integration eventually. As long as the
monzo_creds file stays encrypted and out of a public GH repository, this should
be fairly secure.
This is a bit of a workaround since ideally wpc/ensure-kbds and wpc/kbds minor
mode should eclipse the major-mode's KBDs. I couldn't fully debug the issue, and
in the interest of getting on with things, I resolved to just unbind those keys.
It appears that (auto-fill-mode 1) may be buffer-local. Adding a hook to
fundamental-mode to ensure auto-fill-mode is enabled for most buffers. Stay
tuned, because this may need to be setup for prog-mode-hook as well. Or
neither... we'll see what works.
Sometimes just capturing what I want to buy is as satisfying as actually buying
the item. These org-capture templates really alleviate a lot of the anxiety I
associate with trying to remember many things.
This allows configuration for device specific settings - usually or
perhaps exclusively hardware related. Supporting disabling laptop
touchscreen, increasing laptop cursor speed, reversing the scroll
direction of the laptop mouse.
Until I change my hostname, I'll need to use wpcarro. Internally on
Google networks, this laptop is resolvable via wpcarro.roam.*
Idea: consider defining in ~/.profile:
DESKTOP_NAME=<name>
LAPTOP_NAME=<name>
CLOUDTOP_NAME=<name>
...and then refer to these environment variables throughout my
configuration that depends on them. E.g. -
- configs/install
- configs/uninstall
- .zshrc
- .ssh/config
For now, I'll stick with the path of least resistance.
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.
