fabb
A babashka tasks porcelain inside emacs
tools or deps
external deps and internal emacs tools used
> parseedn
for parsing the bb.edn, deps.edn file
> projectile?
seems like a decent way to find the bb.end/deps.edn - look in the project root
we'll also likely want to fire commands from there
> compilation mode? term-mode?
Need to decide what mode the tasks buffers should run in
notes linked from emacs run-command's readme:
suggested (better?) alternative: term-mode + compilation-minor-mode
prior art
> magit - a git porcelain inside emacs
Built on a UI lib called transient
magit github: https://github.com/magit/magit
magit visual intro: https://emacsair.me/2017/09/01/magit-walk-through/
> emacs
taskrunner
>> doom :taskrunner
https://docs.doomemacs.org/latest/modules/tools/taskrunner/ Doom has a :taskrunner module, but it is deprecated: the docs say it is too trivial, _and_ that upstream taskrunner development has stopped. Could this be extended to support babashka?
> emacs
run-command
great readme to read through. notes on compilation mode: https://massimilianomirra.com/notes/lightweight-external-command-integration-in-emacs-via-compilation-mode/
>> emacs-run-command-babashka-tasks
parses tasks lines from `bb tasks` command, then runs it via `bb <it>`
>> emacs-run-command-clojure-deps
parses deps.edn, runs aliases
has some interesting deps, including one `parseedn` require
>> close-read of the code
This thing is <500 lines and really quite clean! I learned some more emacs primitives in the close read.
One critique is that the mode the command runs in should probably be overwritable per command - i'm not sure why it's not, probably just no one has hit that use-case.
The term/vterm stuff requires a bit of logic to support killing running processes and re-running them - i suppose compiliation mode does that automatically?
I think for v1 fabb i wouldn't support helm at all - maybe we can later, but completing-read and ivy feels like enough.
I also think going harder into the helper functions would be a win. run-command has high utility if you're aware of the compilation-mode commands (for killing and re-running, etc), but fabb could provide a better namespace and more explicit features for re-running commands (through fabb-status, the minor modes, and the magit/transient style interface).
similar to the ink-mode contribution i made, it'll be providing the
replay/replay-with-edited-command in the 'process' buffers, or anywhere else in
the project (fabb status, or maybe a keybinding to popup a lighter-weight status
buffer/hydra/transient of some sort)
interfaces
> transient
The magit-style interface. This could make the most sense, as it provides configuration for toggling options/switches on babashka tasks - though configuring switches/options would require some extra bb.edn task details to be provided or otherwise somehow inferred.
Following the magit-transient docs trail: https://magit.vc/manual/magit/Transient-Commands.html#Transient-Commands
>> transient manual
>> transient compared to hydra (from the transient manual)
> hydra
Y'all know I love me some hydra! Hydra are fast and flexible, and easily expressed and maintained.
> helm / ivy / vertico
Might be simple enough, and familiar enough to folks. Emacs taskrunner has helm and ivy consumers.
What is a 'porcelain'?
The magit readme says only magit and git itself deserver to be called porcelains.
Where did this come from? Does it mean it covers the surface of it?
options/switches
configuring switches/options (through a magit/transient-style ui)
would require some extra bb.edn task details to be provided or otherwise somehow
inferred
right now, babashka tasks don't offer a 'help' that
lists out the way the commands are used, what the
*command-line-args*
are, anything like that.
magit actually lets you edit the options that show up per popup: https://magit.vc/manual/magit-popup/Customizing-Existing-Popups.html So maybe there's some middle-ground for specifying options to bb tasks...
*fabb-status*
buffer
It seems reasonable to offer a
*fabb-status*
buffer that contains a list of the current
and previous task runs.
Magit has a process buffer for running git commands,
which can be seen with
$. There are
some hints for always displaying it:
https://github.com/magit/magit/wiki/Tips-and-Tricks#automatically-displaying-the-process-buffer
Fabb's use-case is slightly different, in that I'd expect to run multiple of these tasks at a time.
> jump to the output of task at point
> re-run task at point
> cancel task at point
> reset/clear output for one
*fabb-process*
buffers (more likely named with the
command and maybe the directory)
> TODO re-run this task
> TODO jump to def (the bb.edn for this task)
> TODO re-run this task with different input
edit it before it fires
running commands via tmux
Personally, i'd love to be able to optionally run bb-tasks via tmux - this would be an extra arm of the fabb code to maintain, but could be an opt-in via the interface when running/re-running a task.
a modeline for running tasks
Would be cool to show some details/number of running tasks, etc in the modeline
use-cases
> bb-release
rschmukler 's helper for processing a changelog, git-tagging, pushing, etc., whenever a library is ready to release a new version.
> clawe/doctor dev
I typically run tasks like `doctor-fe`, `doctor-be`, `styles-watch` when deving against clawe/doctor.
It'd be nice to run those via `fabb`, monitor them via fabb-status
> run tasks for any project
bb.edns can be specified when running `bb`, which means we could support running
bb-tasks from misc other places, if we knew about those other bb.edns
we'd also have to specify the working directory of those places
> test runners
My most common python backend style is a test runners like pytest wrapped in watchmedo, and taking a match-pattern for which test to run against.
I clean up the noise into a `bb test-match
<some-pattern>` usage - getting a shared output or
history (likely just the
*fabb-status*
) for commands like these would be
excellent.
>> on the pytest side of this, there is actually a pytest emacs integration that might be a better move as well
> re-running on file-save might be nice
run-command supports this
somewhat related
> bb alfred workflows
make evaling tasks in-line possible
should be able to c-x c-e (evaluate) bb task code in a bb.edn with fabb
or something close to that
i.e. make not-leaving-emacs to write-and-fire bb.tasks a thing
handling cider connections
first-class neil interface
via transient/hydra?
friendly messages
Backlinks
Welcome to the Clawe garden doc! This file is for thinking and organizing the work on the clawe repo.
- Clawe Repo link
Clawe lets you use clojure and babashka to write wm-level keybindings and manage apps and workspaces.