Combine google-{stuff,tooling}

Google-related files should eventually be moved out of GitHub hosting and onto
Google infrastructure (e.g. Git on Borg).

When I do this, I should run:

```fish
> git grep --ignore-case google (git rev-list --all)
```

To assess the reference I've introduced into this repository.

Other tools that should come in handy when I do this are:
- git filter-branch
- BFG repo-cleaner
This commit is contained in:
William Carroll 2019-12-23 09:02:08 +00:00
parent 96032dbeb0
commit 6cf8517cab
3 changed files with 31 additions and 58 deletions

View file

@ -11,11 +11,9 @@
(require 'kaomoji)
;; Google
(require 'google-tooling)
;; TODO: How should I handle google-stuff.el?
;; TODO: Debug why wallpaper is changing randomly. It seems to happen every 5
;; seconds when init.el is open...
(require 'google-stuff)
;; Laptop XF-functionality
(require 'pulse-audio)

View file

@ -2,7 +2,23 @@
;; Author: William Carroll <wpcarro@gmail.com>
;;; Commentary:
;; Some of this is just encoding my learnings as notes in Elisp format.
;; First, I must opine. Feel free to skip this section. In general, it seems
;; that the typical programmer's workflow suffer from what economists call
;; "inelastic demand". This means that any increase in the price of something
;; plummets the demand. Another way of saying this is that programmers are
;; "price sensitive" when it comes to adopting new workflows.
;;
;; For us, any deviation from our "established" workflow feels costly. This
;; makes sense to me because programming is already mentally taxing, so any
;; additional taxation can sometimes feel unbearable. Until programming changes
;; dramatically and we relieve our dependence on files and text for modeling
;; complex applications, this price sensitivity will most likely remain the
;; status quo. Therefore, it's critical to reduce the price of experimenting
;; with new tools such that new, superior workflows may emerge. In this vain,
;; this module attempts to surface "luxury tools" (i.e. dependency pruners, code
;; linters, code formatters) via Emacs to reduce the price of experimenting with
;; them.
;;; Code:
@ -15,6 +31,7 @@
(require 'evil-leader)
(require 'maybe)
(require 'device)
(require 'macros)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Library
@ -40,6 +57,17 @@ corp to authenticate each other. It's more efficient than SSL and works with
Stubby.")
))
(defconst google-stuff/tools
'(("Depana" . "depana")
("Build cleaner" . "build_cleaner")
("Java formatter" . "google-java-format")
("Proto formatter" . "clang-format"))
"Mapping of names of tools to the names of the executables that run them.")
(use-package protobuf-mode
:config
(macros/support-file-extension "pb" protobuf-mode))
;; TODO: Straighten out fig, citc, google3 and have modules for each.
;; TODO: Move this to a google3.el module.
@ -65,7 +93,7 @@ Stubby.")
("authwf" . "/google3/customer_support/automation/workflow")
("redwood" . "/google3/customer_support/kms/redwood/ui")
("wf-fe" . "/google3/customer_support/kms/redwood/ui/client/components/item/workflow_editor")
("ac" . "/google3/google/internal/alkali/applications/casesconsultservice")
("ac (alkali)" . "/google3/google/internal/alkali/applications/casesconsultservice")
("ac-server" . "/google3/java/com/google/alkali/applications/casesconsultservice/server/")
("ac-server (tests)" . "/google3/javatests/com/google/alkali/applications/casesconsultservice/server/"))
"Mapping of a label to commonly visited locations in Google3.")

View file

@ -1,53 +0,0 @@
;;; google-tooling.el --- Better access to Google tooling -*- lexical-binding: t -*-
;; Author: William Carroll <wpcarro@gmail.com>
;;; Commentary:
;; First, I must opine. Feel free to skip this section. In general, it seems
;; that the average programmer's workflow suffer from what economists call
;; "inelastic demand". This means that any increase in price for something
;; sends the demand plummeting. Another way of phrasing this is that
;; programmers are "price sensitive" when it comes to adopting new workflows.
;;
;; For us, any deviation from our "established" workflow feels costly. This
;; makes sense to me because programming is already taxing, so any additional
;; taxation can feel unbearable. Until programming changes dramatically, and we
;; relieve our dependence on files and text for modeling complex applications,
;; this inelastic demand will remain the status quo. Therefore, it's critical
;; to reduce the price of experimenting with new tools such that new, superior
;; habits may form. In this vain, this module attempts to surface "luxury
;; tools" (i.e. dependency pruners, code linters, code formatters) via Emacs to
;; reduce the price of experimenting with them.
;;; Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Dependencies
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(require 'macros)
;; TODO: Figure out whether or not to integrate with google-emacs.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Library
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defconst google-tooling/tools
'(("Depana" . "depana")
("Build cleaner" . "build_cleaner")
("Java formatter" . "google-java-format")
("Proto formatter" . "clang-format"))
"Mapping of names of tools to the names of the executables that run them.")
(use-package protobuf-mode
:config
(macros/support-file-extension "pb" protobuf-mode))
;; TODO: Call blaze build, use Counsel to select an action, run that action on
;; the nearest BUILD file.
;; TODO: Call build-cleaner on the nearest BUILD file.
(provide 'google-tooling)
;;; google-tooling.el ends here