doctor (clawe project)

Created: Dec 26, 2020Published: Nov 01, 2022Last modified: Apr 24, 2023
Word count: 676Backlinks: 15

A full-stack clojure app with deep tooling integrations.

Presents window management ui components (doctor-topbar) as well as a native or browser-based web app.

doctor: e2e tests for your tools

declarative checkups ( resources/checkups.edn w/ defs)

Each entry is a declarative description of things to check for.

Pull and eval status based on the checkups.

Includes suggestions for how to install if something is missing or out of date. At least a hint at the expected install source.

> build up apis that checking for

  • any binary
  • server-mode running processes

> start to collect follow-ups for

  • installing a thing via pacman/yay
  • creating a systemctl process

> transparent/background check-ups

check if doom is up to date

check if emacs starts without errors

report output of doom doctor

small write up of expectations

maybe :checkup/cron as an option

See also

health check ideas

> health check: tmux session for workspace

> health check: emacs session for workspace

> is ssh-agent started

> has emacs.env been reloaded AFTER ssh-agent started?

> startup health-check that walks through getting things into place

workspace action ideas

  • show cheatsheet
  • show git status
  • fetch latest
  • push latest
  • restarts component (fe, be)
  • rebuild css/styles

feature ideas

> automagic pomodoros

Maybe via doctor chat/notifs?

> doctor 'chat', commentary

  • when a new workspace is opened (or idle for 5 secs?)
  • when a commit is written but not pushed
  • when a break is overdue
  • comments on whatever we're looking at

> rich screenshots

realizing much of my writing moments could be captured as screenshots

goal: a metadata-rich screenshotting tool

v1: clawe/screenshot-full, clawe/screenshot-region bindings

both send a bunch of metadata to a doctor/screenshot or expo/screenshot

(or just to the clawe db?)

doctor app that fetches screenshots from clawe's screenshot db

key-feature: live-updates, similar to yodo's flow

i should be able to demo the thing very impressively

capture and display all the context in the view

just take your pic

>> promotable to things like 'public-garden-note' or 'reddit post'

the screenshot image becomes the 'publish!' moment for something like expo

queuing a post to be published, or updating it if it has already been published

>> screenshots of notes alongside a url

screenshot-update-chess-notes could sync with the running game notes of a

lichess game

grab the url for the current in-wsp browser

sync the moves to an open org-bullet that fits the pattern

>> screenshot metadata has strong overlaps with dock metadata

clients, current open apps, current moves/next steps for those apps

>> screenshots as reviewable checkpoints

they need to collect info from the current context

and make it browsable later

i.e. return me to this session

attach screenshots to stored session state

and let me resume that state at will

buffers, git-diff, everything

pick it up again at that exact moment

time-travel!

> Task/Todo Focus Stack

Support for staying on task, allowing you to opt-in to rabbit holes and later 'pop' that context when you return to the higher level.

Could support keeping docs/cheatsheets/other context on hand for each task.

State via systemic and datalevin?

> react native app (mobile inbox processing?)

get something on ios? drafts is impressing me should be easier to process inboxes/improve content just simple inbox processing

> a kbd-chaining, hydra-like interface

some keybinding that exposes follow up keybindings via doctor-metadata

i need a leader-ish interface to open up some keybindings possibilities

right now i can inject rofi commands ahead of a list of others... maybe this would be a doctor-y interface?

> 'modes' for topbar

is there a current task? here's the focused-layout are you between tasks? looking for the next one? yodo this.

old

> doctor theme

A status update or health-check for any system.

A doctor report might list missing executables, outdated dependencies, or failing unit tests.

The term is useful to ground the use-case - I want my doctor UI to be a useful dashboard that reports problems I might not yet be aware of.

> examples

>> `doom doctor`

Doom's cli and module system has `doctor.el` files that check for expected

binaries and other potential problems (large caches, etc.)


Backlinks

babashka/cli 's -x feature plus arg coercion lets you call arbitrary

functions in your scripts with well formed inputs. It's an excellent

combination, and spurred a clawe refactor (re-achitecture) that I hope to write

up soon. (Though I do have a brief bb-cli note here.)

For today, just want to share a piece of the new structure: clawe.debug/ls and clawe.debug/ls-print.

When debugging clawe, especially clawe's toggle feature, I often need to get a look at the workspaces and clients that are currently running - specifically the names, window titles, class names, etc, which are used to match with client/workspace definitions. When you invoke toggle for "spotify", clawe determines the current need. Are we already focusing spotify? Does the client exist in a different workspace? When this goes wrong, we need to figure out why.

The debug namespace is a quick way to list the clients or workspaces that clawe knows about - (clawe.debug/ls {:type :clients}) in a repl is simple and quite useful.

But sometimes you're not in a clojure repl, or you want to know what a fresh invokation of clawe would see. Maybe the repl state has some advantage or difference from the actual toggle invokation that your keybinding is sending.

> This is especially true for clawe, as I like to develop it against the > fully-featured jvm cider repl (against doctor 's backend server) rather than a > basic bb-repl. This supports extremely useful features like cider-inspect, > and makes clojure development a real joy.

Fortunately, bb-cli's -x lets us invoke the exact command on the command line:

> alias clawebb='bb --config ~/russmatney/clawe/bb.edn'
> clawebb -x clawe.debug/ls-print --type :clients

|           :client/window-title | :client/app-name |
|--------------------------------+------------------|
|                          clawe |        alacritty |
|                          clawe |            emacs |
|                           dino |            emacs |
|                       dotfiles |            emacs |
|            tauri-doctor-topbar |            clove |
|                        journal |            emacs |
|             slack | clojurians |            slack |
|                        spotify |          spotify |
| babashka/cli — mozilla firefox |          firefox |

There we are! We can see that the spotify client is found and properly labelled.

Note that here we're calling ls-print instead, which is a simple wrapper that passes the ls results to clojure.pprint/print-table.

---

A few weeks after this implementation, I started toying with nextjournal/clerk,

and it was a delight to find that clawe.debug/ls can feed directly into

clerk/table, which led to this tiny tmux status notebook:

(ns notebooks.tmux
  {:nextjournal.clerk/visibility {:code :hide :result :show}}
  (:require
   [clawe.debug :as debug]
   [nextjournal.clerk :as clerk]))

;; ### tmux sessions
^::clerk/no-cache
(clerk/table (debug/ls {:type :tmux}))

;; ### tmux panes
^::clerk/no-cache
(clerk/table (debug/ls {:type :tmux-panes}))

---

Another piece of the clawe refactor: Clawe now invokes its keybindings by default with -x.

;; from clawe/defs/bindings.clj
(defkbd toggle-terminal
  [[:mod] "Return"]
  (sxhkd-exec "bb --config ~/russmatney/clawe/bb.edn -x clawe.toggle/toggle --key terminal"))

(defkbd toggle-emacs
  [[:mod :shift] "Return"]
  (sxhkd-exec "bb --config ~/russmatney/clawe/bb.edn -x clawe.toggle/toggle --key emacs"))

(defkbd toggle-workspace-journal
  [[:mod] "u"]
  (sxhkd-exec "bb --config ~/russmatney/clawe/bb.edn -x clawe.toggle/toggle --key journal"))

(defkbd toggle-workspace-web
  [[:mod] "t"]
  (sxhkd-exec "bb --config ~/russmatney/clawe/bb.edn -x clawe.toggle/toggle --key web"))

Prior to this, I was using a defthing macro to register commands, and invoking them by passing the name into clawe's main function.

This change simplified the architecture by completely removing that registry,

and has the added benefit of making it very simple to reproduce an invokation -

you can just invoke it yourself:

bb --config ~/russmatney/clawe/bb.edn -x clawe.toggle/toggle --key journal

This ends up being more performant as well - there's no need to require every namespace in clawe to call one command. When invoked via -x, only the required namespaces are loaded, so we get to the good bits right away.

---

For more on Clawe's features and design journey, check out the clawe workspace note.

A full-stack clojure app with deep tooling integrations.

Presents window management ui components (doctor-topbar) as well as a native or browser-based web app.

A feature of Doctor.

Intended as a workspaces-widget replacement.

Your workspaces and the apps they are responsible for.

Shows all the open workspaces, the active workspaces, the recently deleted ones. The amount of visible information is toggleable (modes, cycling levels of detail ).

The apps that are open (or could be opened) in those workspace and their statuses/urgencies/health-checks should be visible as well.

Could toggle to show related keybindings in context

i.e. press mod+s to toggle

So you want to create a quick native dashboard. You know enough web dev to be dangerous, and now you're hoping to create something useful that isn't stuck in one of your browser tabs.

Here I'll touch on the path I took through Electron that eventually lead to Tauri, then include links to the way I'm currently using Tauri in Clawe.

aka status check.

This was the original intent of doctor

i (of course) blew it out into an unfinishable doctor dashboards 'project'. (feel the disdain in those words)

nothing like an overengineered doctor.

A video overview of the components that make up the clawe monorepo.

Relevant April 2023.

I'll post a link here once it exists! For now, if you're reading this, I could stream this any day, so take a look at my schedule or ping me to see when it's going to happen.